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Session types capture precise protocol structure in concurrent programming, but do not specify prop- 
erties of the exchanged values beyond their basic type. Refinement types are a form of dependent 
types that can address this limitation, combining types with logical formulae that may refer to pro- 
gram values and can constrain types using arbitrary predicates. We present a pi calculus with assume 
and assert operations, typed using a session discipline that incorporates refinement formulae written 
in a fragment of Multiplicative Linear Logic. Our original combination of session and refinement 
types, together with the well established benefits of linearity, allows very fine-grained specifications 
of communication protocols in which refinement formulae are treated as logical resources rather than 
persistent truths. 

1 Introduction 

Session types |'9l are a practical and expressive type-based verification methodology for concurrent 
programming, and have proved excellent in modeling typed computations predominantly consisting of 
client-server message passing. As a simple example, assigning the type !int.?bool.end to a communica- 
tion channel means that a value of type int will be sent (!int), then a bool will be received (?bool), and 
the channel cannot be used any further. Communication soundness is ensured when the "other end" of 
the communication channel is used in a complementary (or dual) way: !int.?bool.end = ?int.!bool.end. 

Refinement types, as defined for ML 1 6], are a form of dependent types that allow the programmer to 
attach formulae to types, thus narrowing down the set of values inhabiting a given type. For instance, the 
type {.X : int I < X A.X < 10} describes integer values in the range 0..10. Such fine-grained types have 
met increasing attention, with several notable works on type checking for functional programming, such 
as hybrid type checking Q, liquid types |[T6l . or the blame calculus |[T9i . In the context of this work, let 
us note that refinements for ML written in Intuitionistic Linear Logic have been introduced in [11]. A 
detailed overview is in 1^]. 

With regard to refinement formulae, the most common approach is to use classical first-order logic, 
which is certainly enough for many examples, but cannot provide a satisfactory treatment of refine- 
ments on resources. In particular, it does not allow one to control finer computational properties: a type 
{x: ccard | use(x)} may mean that we can use a credit card, but it does not mandate that we can do so 
just once. To achieve such finer distinctions between types, we specify refinements in a fragment of 
multiplicative linear logic (MLL) [7], most notably without exponentials or additives. 

Building on previous work on session types lITSl . we combine sessions and linear refinements to ob- 
tain an original system of linearly refined session types, noting that until now neither linear nor classical 
refinements have been studied in the context of session types, according to our knowledge. The result 
is a system in which typed message exchange, refinement, and resources are combined, providing for a 
very fine control of process behaviour. We show that well-typed programs do not get stuck when trying 
to verify logical properties. 
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The rest of the paper is structured as follows. Section [2] introduces the language and its operational 
semantics, as well as the running example. Section[3]describes the typing system and Section|4]the main 
results. We conclude the paper with related work and future directions. 

2 The pi calculus with assume and assert 

Consider a simple online Store that accepts a product request from a Client, and interacts with a Bank 
to perform the payment. The Store and the Client share a private channel in which the Client sends the 
product p, the credit card number c and the price it is willing to pay, €100. The Store acts dually by 
accepting the product, the credit card, and the amount to be charged, and by immediately charging, using 
Charge(c,<3), the amount a to the credit card c. 

Client = 51 !p.5i!c.5i 1100.0 Store = 52?^'-^2?c.52?a-Charge(c,a) 

In the code above, s\lp means to send the value p on channel endpoint ^i, dually 52"^ p means to read 
a value from ^2 binding it to variable p, and denotes the terminated process. Value p should not be 
confused with variable p. In our language processes read and write within sessions by using distinct 
variables to identify the two ends of the channel, si and S2 in this case. 

In order to charge the Client, the Store calls the Bank service, and sends the credit card number and 
the amount to be charged. 

Bank = ^i^rily.ylc.yla.O Charge(c,fl') = {new bib2){r2^-b2-bilc.bila.O) 

In the Bank code, * prefixes a replicated process that can be used an unbounded number of times, as 
one would expect in this example. The Charge process creates a new channel with the (new ^1^72) 
constructor, whose purpose is to establish a private, bidirectional channel with the bank. To set up the 
session, the channel endpoint b2 is passed to the bank and the other, bi,is retained locally for interaction 
with the bank. Note that the language is explicitly typed, but for brevity we ignore the type annotations 
in our examples. 

The overall system is the parallel composition of the three processes connected by two channels: 
rir2, the public Bank-Store channel, and siS2, the private Client-Store channel. 

(new rir2)(new 5i5'2)(Client | Store | Bank) 

The syntax of processes is presented in Figure [T] The linear nature of sessions, for example in the 
session S1S2 between Client and Store, can ensure some security properties. By enriching such a calculus 
with cryptography primitives, more properties can be captured, such as authentication requirements and 
privacy of communication (e.g. f2]). However, even if such properties ai^e satisfied the system can contain 
unintended uses of given permissions by authorized processes. In the above example, the Store can 
wrongly compute the amount to be charged, which will be detected only later by the Client. 

Storei = 52?/'"^2?c.52?a-Charge(c,a + 10) 

A more subtle situation is when two threads try to charge the Client for the same purchase. 

Storei = S2?/'-5'2?c.52?«-(Charge(c,fl;) [ Charge(c,<3)) 

Our language enriches pi calculus with assume and assert commands, using formulae (p built over a 
set of uninterpreted predicates A,Ai,A2, ■ ■ ., the linear logic connective of tensor, (g), and its identity, 1. 
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(p ::= Formulae: 
A(vi , . . . , v„) predicate on vi , . . . , v„ 



1 



joining 
identity 



V ::= 



X 





Values: 
variable 
unit 



x\v.P 
xlx.P 

p\p 
*p 



(new XX : T)P 
(assume (p)P 
assert (p.P 



Processes: 
output 
input 

parallel composition 
replication 
inaction 
scope restriction 
assume 
assert 



Figure 1 : The syntax of processes 



The predicates may refer to channel names or base-values such as integers and strings, which are rep- 
resented here by the unit value, (); therefore, refinements form dependent types. Enhanced with these 
commands, the Client may assume a charge {c, 100) capability on the values sent to the Store. And the 
Bank, in turn, will assert that exact capability. 

Clienti = (assume charge{c, 100))Clieiit Banki = *rily.ylc .yla. assert charge{c,a).0 

In order to explain the interplay between assume and assert, we turn our attention to the operational se- 
mantics of the language. We say that variable y occurs bound in process P within xly.P and {newxy : T)P, 
in type U within qly: T.U and q\y: T.U, and in formula (p within {y: T\(p}. Also, variable x occurs 
bound in (new xy : T)P. A variable that occurs in a non-bound position within a process, type, or formula 
is said to be free. The sets of free variables in a process P, a type T or a formula cp, denoted by fv(P), 
fv(r) and fv((p), are defined accordingly and so is alpha-conversion. We work up to alpha-conversion 
and follow Barendregt's variable convention, whereby all variables in binding occurrences in any math- 
ematical context are pairwise distinct and distinct from the free variables. 

The standard capture-free substitution of variable x by value v in process P, a type T or a formula (p, is 
denoted by /'[v/jt], (j!>[v/x] and r[v/x]. This follows the standard treatment for dependent session/channel 
types |[T2ll20l . For example, the substitution ((newxy: T)P)[v/z] is defined as [newxy: T[v/z])P[v/z]- 

From the operational semantics we factor out a heating relation meant to simplify the statement of 
the reduction relation, by structurally adjusting processes. Both relations, heating and reduction, are 
defined in Figured We start with reduction. The relation includes the rule for communication, R-COM, 
adapted from ifTSl to handle dependent refinements, and the usual rules for reduction underneath parallel 
composition and restriction, R-Par, R-Res, and under heating with R-Heat. It also includes two 
novelties: an axiom R-ASSERT for cutting assertions, and a rule that allows reduction under assumptions, 
R-ASSUME. The correspondence of R-AsSERT with the logical cut is evident, noting that a choice has 
been made for assumptions to define a scope and for the cut to take place against enclosed assertions. The 
alternative would be for the cut to take place between an assume and an assert in parallel, but at the typing 
level this would require a form of negation which would effectively identify assumptions and assertions; 
instead of asserting cp one could assume cp^ and the two possibilities would be indistinguishable at the 
typing environment level. As a result, two assumes could cancel out each other, and similarly for two 
asserts, thus compromising the intended usage of assertions. 
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Heating relation, P^Q {P = Q means P ^ QwdQ^ P) 

P\Q = Q\P {P\Q)\R = P\{Q\R) P\Q = P *P = P\*P (newxy:r)0 = 
(newxy: T){P \ Q) = {new xy: T)P\Q (newwz: r)(newxy: U)P = {newxy: U){newwz: T)P 

(new xy: r)(assume <p)P = (assume <p)(newxy: r)? (assume l)? = P assert l.P = P 
(assume <pi)(assume ^)P= (assume <P2)(assume (Pi)P assert <pi .assert (p2.P = assert <p2-assert (pi.P 
assert (pi ®(p2-P = assert <pi .assert (pi P (assume <pi ® ^)P = (assume 91) (assume ^)P 
(assume 9)P I (2^ (assume 9) (P I O) {new xy: T)P = {new xy: U)P HT = U 

Reduction relation, P ^ Q 

(newxy: {q\w: T.U)){x\v.P \ ylz-Q \ R) -> {newxy: U[v/w]){P \ Q[v/z] \ R) (R-COM) 

(assume <p) (assert (p.P \Q) ^ P\Q (R-ASSERT) 

P ^ Q P ^ Q 

^ (R-ASSUME, R-Res) 

(R-Par, R-Heat) 



(assume <p)P — >■ (assume <p)(2 (newxy: T)P — > (newxy: T)Q 

P^Q P^P' P'^Q' Q'^Q 

P\R Q\R P ^ Q 



Figure 2: Operational semantics 



On what concerns heating, the rules in the first two lines are standard in the pi calculus, those in the 
following three lines manipulate assume and assert processes, as well as linear logic formulae, in the ex- 
pected way. The last line introduces the only truly directional rule, allowing the scope of an assumption 
to encompass another process. The reason why the rule is not bidirectional is because we want to keep as- 
sertions in the scope of assumptions; take for example a process P of the form (assume A)(0 | assert A.O). 
We have that P reduces in one step to 0, but (assume A)0 | assert A.O is stuck. With assume, and un- 
like scope extrusion, i.e., (newxy)/" | Q = {new xy){P \ Q), we do not have bound variables to control the 
application of the rule. The last rule in the figure allows to expand a recursive type, paving the way appli- 
cations of rule R-COM. Notice that we do not mention the usual sideconditions, e.g., thatx,y ^ fv {Q) 
in the scope extrusion rule, since the variable convention can be assumed to provide this guarantee. 

In the example, by heating, the (assume c/ifl;rge(c, 100)) can be extended to encompass the Store 
process, and then moved to a position before session creation (new s\S2) to allow the interaction between 
the Ghent and the Store on channel S1S2, via the R-COM rule. 

(new i'i5'2)(Clienti | Store) ^ 

(assume c/jarge(c, 100)) (new 51^2) ('S'l !p.5i !c.5i ! 100.0 | S2?/'"5'2?c.52?fl^-Charge(c,a')) — > 

(assume charge{c, 1 00)) Charge (c, 100) 

Next, the process is ready to perform the communication between Banki and Store. Rule R-Assert 
matches the assume with the assert, and the process is concluded. 

(new rir2)(assume charge{c, 100)) (Charge (c, 100) | Banki) = 

(assume charge{c, 100))(new ri r2) (Charge (c, 100) | rily.ylc.yla.assert charge{c,a) \ Banki) 

assume charge{c, 100) assert charge{c, 100).0 | (new rir2)Banki — )• (new rir2)Banki 
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Clearly, if Storci is used, the reduction will yield a process where the assumption and the assertion 
do not match. 

(new n''2)(new5i52)(Client | Storei | Banki) ■ ■ ■ ^ 

assume charge {c, 100) assert charge{c, 110). | (new rir2)Banki -/^ 

In turn, if Storei replaces Storei in the above process, then we reach a situation where one assertion 
is left unmatched. 

(new rir2)(newsiS2)(Client 1 Store2 | Banki) assert c/jarge(c, 100). | (new rir2)Banki 7^ 

These two processes are stuck due to assume/assert problems — in both cases we find an assert for 
which no corresponding assume exists in the enclosing scope — and will be identified as unsafe by the 
typing system. 

If somehow the client wants to be charged twice, then it can assume charge{c, 100), twice in a row. 
Alternatively it may utilise a more compact variant by using joining (tensor). 

Client2 = (assume charge(c, 100) 'S>charge{c, 100))^! \p.si !c.5i ! 100.0 

Then, by taking advantage of the heating rule that allows breaking the {(E>), as well as reduction under- 
neath assumptions, we can easily see that: 

(new rir2)(new 5i5'2)(Client2 | Storei | Banki) —>•••—)■ (new rir2)Banki 

We conclude this section by defining what we mean by a safe process. First we introduce the notion 
of canonical processes. A process is in canonical form if it is of the form: 

{new xiyi : Ti) - ■ ■ (newx/^yic : r|.)(assume Ai) • • • (assume A,„) (Pi [ • • • | Pn) with k,m >0,n > 

and every Pi is neither a new, nor an assume nor a parallel composition. A simple induction on the struc- 
ture of processes easily allows us to conclude that all processes can be heated to a process in canonical 
form. 

Then, we say that a process Q is safe if, for all processes P in the canonical form above such that 
P and every Pi of the form assert B,./?,, there is a 1 < 7 < m such that B, = Aj. In other words, safe 
processes do not get stuck at assertion points. The next section introduces a type assignment system that 
guarantees that processes typable under unrestricted contexts are safe. 

Notice that each A,- and B,- are atomic formulae; if not, then the heating relation may "break" the 
tensors (®) and eliminate the identities (1), so that in the end we may match assumptions on atomic 
formulae against assertions on atomic formulae. 

3 Typing system 

The syntax of types is presented in Figure |3] Let product, ccard and nat be the types of the products sold 
by the store, credit cards, and natural numbers respectively (all denoted by unit in the figure). The types 
of the two ends r\r2 of the Client-Store channel, and also of the Bank-Store channel s\S2, are as follows. 



Si : lin!product.lin!ccard.lin!nat.end 
ri : /XO;.un?(lin?ccard.lin?nat.end).o; 



S2 : lin?product.lin?ccard.lin?nat.end 
r2 : /XOt.un!(lin?ccard.lin?nat.end).o; 
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q ::= Qualifiers: qp qualified session 

lin linear {x: T\(p} refinement 

un unrestricted a type variable 

p ::= Session types: ixa.T recursive type 

Ix: T.T receive F ::= Contexts: 

\x: T.T send • empty 

T ::= Types: T^x: T type assumption 

unit unit F, <p formula 

end termination 



Figure 3: The syntax of types and typing contexts 

In types, as in processes, ! means output and ? means input, end denotes a channel on which no further 
interaction is possible, and the li construct is used to write recursive types. Quahfiers lin and un are used 
to control the number of threads holding references to the channel end: exactly one in the lin case, zero or 
more for the un case. The Client-Store chaimel is lin at all times, so that a third process cannot interfere in 
the interaction. The Bank-Store channel is un at all times, so that multiple stores may connect to the bank. 
Such a un channel is used to pass a lin channel (of type lin?ccarcl.lin?nat.end), thus estabhshing a private 
channel between the Bank and the Store. In our example, we assume that the private Client-Store channel 
was created via a similar mechanism, based on some shared channel provided by the store. It should be 
easy to see that the type lin!product.lin!ccard.lin!nat.end of the s\ end of the channel naturally describes 
the Client's interaction s\ Ip.^i !c.>yi ! 100.0, and that the type un!(lin?ccard.lin?nat.end) . . . closely explains 
the Store's interaction r\ ly.ylc.yla . . . 

The above typing context is correct for process Client | Store | Bank, but it remains so even if one 
replaces Store by Storei or by Store2, since in both of these cases the usage of the channels match the 
prescribed behavior. Thus, traditional session types are not enough to control and discipline the use of 
resources. 

In order to incorporate logical information into session types, the syntax is augmented with logical 
refinements, {x: T\(f)}. Further, and in order for formulae (p to be able to refer to data appearing "previ- 
ously" in types, we name the object of communication: in type qlx: T.U we allow type U to refer to the 
value received before via variable x. Types can be refined with the exact same formulae used for assert- 
ing and assuming in processes. For example, the types for chaimels s\ and r\ can be logically refined in 
such a a way that the amount x to be charged is subject to "permission" charge{c,x), where c denotes the 
credit card number received in a previous communication. 

Jl : lin!;?: product.linic: ccard.linia: {x: nat\charge{c,x)}.end 
n : ixa.unly: (lin?c: ccard.lin?a: {x: nat\charge{c,x)}.end).a 

We will get back to our running example after introducing the type system. 

For recursive types, type variable a occurs bound in type [xa.T. Such types are required to be 
contractive, i.e., containing no subexpression of the form fiai . . . HCCn-OCi. We further require types not 
to contain subexpressions of the form /itti . . . /io^.jx: T | <p}, so that the only interesting recursive types 
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The dual of a type, T = T 

qlx: T.U = q\x: T.U q\x'. T.U = qlx: T.U end = end jla.T = ixa.T a = a 

Unrestricted types and contexts, un(r) and un(r) 

un(unit) un(end) un(unp) 
un(-) un(r,x: T) if un(r) and un(r) 

Well-formed formulae, T l-„f <p, well-formed types, T l-„f T, and well-formed contexts, l-„f T 

fv((p) c dom(r) fv(r) c dom(r) ^ _ h„fr rh^^r h^^r vK^tp 

ri-„f(p ri-„fr ™' i-„fr,x:r i-„fr,(p 

Figure 4: Type duality, unrestricted predicates, and well formed predicates 

are session types. We leave the treatment of recursive refinement types for future work, where they may 
represent the introduction of persistent formulae, i.e., the exponentials of linear logic. We again follow 
Barendregt's variable convention, this time on type variables a. 

Type equivalence is a central ingredient in dependent type systems. Here we stick to a rather simple 
notion. The equivalence relation of formulae is the smallest equivalence relation, denoted by =, contain- 
ing the axioms (pi® (p2 = (pi® H>\ and (p 1 = (p. For types, we include in the equivalence relation a 
recursive type pLa.T and its unfolding T[iJLa.T / a], as well as refinement types that differ on equivalent 
formulae only. The definition, omitted, is co-inductive. 

Duality plays a central role in the theory of session types. The two ends of a channel are supposed 
to be of a dual nature at certain points in typing derivations, namely at scope restriction (new xy: T)P. 
Examples include the types for variables s\ and ^2, as well as those for variables r\ and r2 above. The 
definition is in Figure ID Duality is defined only for session types (input, output, end, and recursion); in 
particular it is undefined for refinement types in very much the way as it is undefined for unit ifTSl . 

Typing contexts are defined in Figure [3] and include type assumptions for variables, x: T, as well as 
formulae (p known to hold. The domain of a context Y, denoted dom(r), is defined as {x | x: T € F}. 

Types (and contexts) can be classified as unrestricted or linear, we only need the first notion; the 
definition is in Figured Unrestricted types, denoted un(r), are unit, end and un p for all p. Unrestricted 
contexts may contain unrestricted types only, in particular they cannot contain formulae (for these are 
linear). 

Formulae may contain program variables. Because types may include formulae, types may con- 
tain free program variables. Formulae and types are well formed with respect to a context if their free 
variables are in the domain of the context. Contexts contain formulae and types. Formulae and types ap- 
pearing in a context must be well formed with respect to the "initial" part of the context. The definitions 
of well formed contexts is in Figure IH In particular, our system does not include (imphcitly or explicitly) 
the exchange rule; context x: unit,A(x) is well formed but A(x),x: unit not. 

Central to our type system is the context split operator that distributes incoming formulae and linear 
types to one of the output contexts while duplicating incoming unrestricted types to both the output 
contexts. The definition, a straightforward extension of the one in [18| that can now handle formulae, 
is in Figure |5] Formulae in contexts are handled very much like linear type assumptions: there is one 
rule to "send" the formula (or type assumption) to the left context and one rule to send it to the right. 
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Context split, T = ToT 



= 0o0 



r = rior2 



rii-„fiinp r = rior2 



r2 l-„f linp 



T,x: T = (r\,x: 



r = rior2 



r)o(r2,x: T) 



r,x: lin p = 
un{T) 



{Ti,x: linp)or2 r,^:: \\np = 

r = rior2 ri\-„f(p 
r,<p = (ri,(p)or2 



Ti o(r2,x: lin;?) 

r = rior2 r2h„f(p 
r,(p = rio(r2,(p) 



Context update, T + x : T = T 



x^dom(r) Th^fT 
T + x: T = T,x: T 



(r,x: r)+x: T = {T,x: T 



un(r) 



Figure 5: Context split and context update 



There are however new assumptions, T l-„f (p and T l-„f lin/?, meant to guarantee that the output of context 
splitting are well-formed contexts. The context update operator is used to update the type of a channel, 
after its prefix has been used. It is used in the typing rules for input and output processes. 

We are finally in a position to introduce the type system; the rules are in Figure [6l Sequents for 
extracting formulae from contexts are of the form F h <p; sequents for values are of the form F h v: T , 
and for processes of the form F h The rules for formulae should be easy to understand. All our rules 
make sure that at the leaves of derivations there are only well-formed, unrestricted contexts, so as to 
make sure all linear entities (formulae and types) are used in a derivation. The rules for values follow 
a similar pattern; they include conventional rules for refinement introduction and for type conversion. 
The first six rules for processes are taken from ifTSl . For instance, the rule for output splits the incoming 
context in three parts, one to type the subject x of communication, the other to type the object v, and the 
third to type the continuation process P. The context for P is updated with the new type for x, that is the 
continuation type U with the appropriated substitution applied. 

For example, in order to type the final part 5i ! 100.0 of the Clienti process under context: 



we split the context in three parts: c: ccard,5i : lin!a: {x: r\zt\charge{c ,x)} .end to type variable s\, con- 
textc: ccard, c/zarge(c, 100) to type value 100 and context c: ccard + si: end[100/<3] = c: ccard,si : end to 
type the continuation process 0. From the context for value 100, we build the type {x: nat|c/jarge(c,x)} 
that matches the "initial" part of the type for s\. Formula charge{c, 100) is introduced in the context via 
the typing rule for assume (see below). 

The novelties of the type system are the rules for assume and assert, and should be easy to understand. 
Rule T-ASSUME adds to the context the formula assumed in the process. Rule T-ASSERT works in the 
opposite direction, removing from the context the assertion. Also novel to our type system are the three 
rule for the elimination of 1, (g) and refinement types. These rules work in the context, hence are rules 
for processes. The corresponding introduction rules work on the entities (types and formulae) extracted 
from the context, and are thus rules for formulae and values. 

B ack to the running example, let B2 =MO;.un!y: (lin?c: ccard.lin?a: {x: nat[c/Mr^e(c+ 10,x)}.end).OI 
be the type of a bank as seen from the side of the Storei (the type of r2). Even though we can derive 



c: ccardj^i : lin!a: {x: nat|c/iarge(c, x)}. end, c/iarge(c, 100) 



s\'. \\n\p\ product. Iin!c: ccard.linla : {x: nat|c/zfl'rge(c,x)}.end, 

^2: lin?7:>: product. Iin?c: ccard.lin?a: {x: nat|c/iarge(c+ 10, x)}. end, r2 : B2 l~ Client [ Storei 
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Typing rules for formulae, F h <p 

h^fT un(r) h,fri,<p,r2 un(ri,r2) nhcpi Vi^cpi 



(T-lI,T-FORM,T-(g)I) 



rhi ri,<p,r2h<p rior2h<pi®<P2 

Typing rules for values, F h v : T 

h^fT un(r) h^ri,x:r,r2 un(ri,r2) rih<p[vA] r2hv:r rhv:ri Ti = T2 



rh(): unit 



FijX: T,r2 \- x: T 



rior2hv: {x: r I <p} ri-v:r2 

(T-Unit,T-Var,T-RefI,T-Conv) 



Typing rules for processes, F h P 

H^fT un(r) Fi h Pi r2 h P2 rh^fT r,x:T,y:ThP un(r) ThP 

rho rior2i-Pi|P2 rh(newxy:r)p r\-*p 

(T-End,T-Par,T-Res,T-Rep) 

ri\- x: {q\y: T.U) r2\-v:T Fs+x: U[v/y]\- P 



Ti or2or3 \- x\v.p 

rihx: {qly: T.U) (r2,z: T)+x: U[z/y]\- P 

rior2hx?z.p 
r2h<p rior2hP Ti h <p r2 h p 

Fi h (assume <p)P Fi or2 h assert <p.P 

rhp ri,(pi,(p2,r2hp ri,x: T,(p[x/y],r2h p 



r,i\-p ri,(pi®92,r2hP Fux: {y. t \(p},r2^p 



(T-OUT) 
(T-IN) 

(T-ASSUME,T-ASSERT) 
(T-1E,T-(8)E,T-RefE) 



Figure 6: Typing rules 

we cannot derive r2 : B2 l~ (new 5'i52)(Clienti | Store) for the types for .vi and S2 are not dual, because 
type {x: nat\charge{c,x)} is not equivalent to {x: ml\charge{c + 10, x)}, as required by rule T-Res. 

The case of Store2 is of a different nature, and in particular it is not typable due to the impossibiUty 
of a suitable context spUt. One would like to type Storei under context: 

S2'. WnTp: product. I in?c: ccard.lin?a: {x: nat|ctorge(c,x)}.end,r2 : B'2 



where B'2 is type B2 above with charge{c,x) replacing charge{c+ 10, x). Typing the initial part of the 
process, using rule T-lN three times, we introduce in the context the following entries: p: product, 
c: ccard, and a: {x: nat\charge{c,x)}. Then, using refinement elimination rule, T-RefE, we convert the 
last entry in a: nat, charge {c, a). Now, in order to type the continuation Charge(c,x) | Charge(c,x), we 
have to split the context, but there is one only formula charge {c, a) in the incoming context, so that only 
one of the threads will be typable. 

On the other hand, consider the case of Clienti above that assumes twice the capabihty charge {c, 100). 
By duality of sessions, the type of the value received by the store will also be refined with a double ca- 
pability, a: {x: nat\charge{c,x) charge {c,x)}. Then we use T-RefE followed by T-(8)E to obtain 
a: nat, charge (c, a), c/zarge(c, a), making possible the split a: nat, charge {c, a) o a: nat, charge {c, a). 
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4 Main results 

The central result of this paper follows from the lemmas for weakening, strengthening and substitu- 
tion ifTSl extended to this system, as well as from basic properties of context splitting (details omitted). 

Lemma 1 (Weakening). IfF h P and un{T), then r,x :T \- P. 

Lemma 2 (Strengthening). lfT,x : T \- P, un{T) and x ^ fv{P), then T h P. 

Lemma 3 (Substitution). IfT\ \-v:T and T2,x : r,r3 h P, then T\ o (r2,r3[v/x]) h P[v/x]. 

Lemma 4 (Preservation for ^). IfT\- P and P ^ Q, then r\- Q. 

Theorem 5 (Preservation for -^). IfVh P and P ^ Q, then Vh Q. 

Theorem 6 (Safety). IfT\- P and un(r), then P is safe. 

It should be easy to see that processes typable under arbitrary contexts may not be safe; take for 
example A h assert A.O. 

Finally, combining the two results above with a simple induction on the length of reduction we obtain 
the main result of the paper. 

Corollary 7 (Main Result). IfTh P with un(r) and P reduces to Q in a finite number of steps, then Q is 
safe. 

The result states that processes typable under unrestricted contexts do not get stuck at assertion 
points (they may still block at input or output points, due to deadlock). Furthermore we also know that 
all assumptions are eventually matched; e.g., process (assume A)0 is not typable. In the case of typable 
processes it is therefore safe to erase all the assumptions and assertions from a process, so that there are 
no formulae at runtime. 

For the cases in proofs involving formulae we make use of the notion of canonical contexts, that 
is, contexts containing no refinement types (x : T € F implies T is not a refinement type) and whose 
formulae contain no connectives ((p € F implies (p = A). Contexts can be converted in a canonical form 
by using the cf function, defined on contexts, type assumptions, and formulae. 

cf(-) = - cf(F,(p) =cf(F),cf(<p) cf(F,x: r) =cf(F),cf(x: r) 
ci{x : {y : T\(p}) = cf(x : T),ci{(p[x/y\) cf(x : T) = x : T if T is not a refinement 
cf(l) = - cf((pi (g)(p2) =cf((pi),cf(92) cf(A)=A 

We then establish a result, F h P iff cf (F) h P, allowing to consider contexts in their canonical form. 

5 Related Work, Conclusions and Future Plans 

Refinements have been useful in verifying polymorphic contracts fV\, security protocols 0, and with 
the improvements in satisfiability-modulo-theories (SMT) solvers for classical first-order logics with 
uninterpreted functions (such as lfT4i ). can be integrated into type systems using off-the-shelf components 
as has been done for the language F# using the F7 typechecker ifTSl . 

In the context of sessions, Bonelli et al. system of correspondence assertions for process synchroniza- 
tion [4 1 is close to a basic form of refinement, as it allows labels to be used in the participant processes 
of a session to signify the starting and ending points of marked protocol sections. This type of protocol 
segmentation can be thought of as a basic assume/assert mechanism with conjunction, since multisets 
of labels can be used for the part equivalent to 'assert,' but still without the rich constructors and proof 
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system of a logic. Bocchi et al. introduce assertions in multiparty session types (session types allowing 
to describe interaction among multiple partners) f3]. Similarly to the system of Bonelli et al. f4], asser- 
tions are explicitly associated with session operations (in, out, branch, select). In contrast, our system 
introduces assertions as refinement types to be used at arbitrary places in a protocol; furthermore their 
system uses classical logic as opposed to linear logic. 

The recent work by Toninho et al. [17] interprets session types within intuitionistic linear logic, 
obtaining (with some extensions) a dependent sessions type system for Ti-calculus. This system interprets 
session types as linear logic formulae, with input as -o and output as Cg), and stratifies the language 
into a ;r-calculus for communication and a functional language for proof objects, where the latter are 
opaque terms that (in our system) would correspond to proofs of refinements. However, their system 
does not consider linear refinements, i.e., linearity is restricted to the communication layer (the sessions). 
Although the aims of both systems are similar to an extent, we have taken a different approach, adopting 
session types without their linear-formulae interpretation, and focussing on the incorporation of fine- 
grained linear refinements which provide for a more delicate distinction between types. Moreover, we 
do not utilise proof-witnesses but rather implement proof search within the type system itself; then, 
using the heating relation, assumptions are manipulated at runtime in order to check assertions, which is 
essentially a procedure of cut-elimination. 

The concept of names appearing in types was pioneered in the work by Yoshida on channel-dependent 
types for processes with code mobility [20], and was adapted to sessions in subsequent work [il2l1 . In 
these systems there are no refinements, yet channel dependent types are shown to provide security guar- 
antees by controlling which names may be used in communications between received code and host 
environment, which indicates that an integration with our system could provide even greater control over 
mobile code. 

In summary, a theory of (linear) refinement types for sessions has not been hitherto proposed, mark- 
ing the contribution of our system. As future work, it is interesting to consider sessions as linear refine- 
ments, and to extend our refinement language to a larger fragment of Linear Logic. We plan to investi- 
gate decidable type-checking, drawing inspiration from the techniques in ||5l[l6l[l8l, and by considering 
appropriate restrictions. Moreover, it would be interesting to examine the adaptations necessary for lan- 
guages with (asynchronous) buffered semantics, where communications can be reordered, especially in 
the context of mobile session-typed processes |[T3l . channel dependent types lfT2l |20]| . and multi-party 
sessions |TOl. 

Acknowledgements. This work was supported by projects Interfaces, CMU-PT/NGN/0044/2008, 
and Assertion-types, PTDC/EIA-CCO/105359/2008. 



References 

[1] Joao Belo, Michael Greenberg, Atsushi Igarashi & Benjamin Pierce (2011): Polymorphic Contracts. In: 
Programming Languages and Systems, LNCS 6602, Springer, pp. 18-37 do H10.1007/978-3-642-19718-5_2| 

[2] Karthikeyan Bhargavan, Cedric Fournet & Andrew D. Gordon (2010): Modular verification of security 
protocol code by typing. In: POPL'IO, ACM, pp. 445^56, doi: 10.1145/ 1706299.1706350 Available at 
.10. 1145/1706299. 170 6350, 

[3] Laura Bocchi, Kohei Honda, Emilio Tuosto & Nobuko Yoshida (2010): A theory of design-by-contract for 
distributed multiparty interactions. In: Proceedings of the 21st international conference on Concurrency 
theory, CONCUR' 10, Springer, pp. 162-176 doi ]10.1007/978-3-642-15375-4_12| 



p. Baltazar, D. Mostrous & V. T. Vasconcelos 



49 



[4] Eduardo Bonelli, Adriana Compagnoni & Elsa Gunter (2005): Correspondence Assertions for Process 
Synchronization in Concurrent Communications. Journal of Functional Programming 15, pp. 219-247 
doi: 10. 1017/S095679680400543X 

[5] Cormac Flanagan (2006): Hybrid type checking. In: Conference record of the 33rd ACM 
SIGPLAN-SIGACT symposium on Principles of programming languages, POPL'06, ACM, pp. 245-256 
doi: 10. 1145/1 11 1037.1 11 1059 

[6] Tim Freeman & Frank Pfenning (1991): Refinement types for ML. In: PLDI'Pl, ACM, pp. 268-277 
doi il0.1I45/I13446.lT3468l 

[7] Jean- Yves Girard (1987): Linear logic. Theoretical Computer Science 50, pp. 1-102 
doi: 10. 1016/0304-3975(87)90045-4 

[8] Andrew Gordon 8c Cedric Fournet (2009): Principles and applications of refinement types. TR 147, MSR 
doi : 10.3233/978- 1 -60750- I00-8-73I 

[9] Kohei Honda, Vasco T. Vasconcelos & Makoto Kubo (1998): Language primitives and type disci- 
pline for structured communication-based programming. In: ESOP'98, LNCS, Springer, pp. 122-138 
doi ]TaT007/BFb0053567l 

[10] Kohei Honda, Nobuko Yoshida & Marco Carbone (2008): Multiparty asynchronous session types. In: 
POPL'08, ACM, pp. 273-284, doi: 10.1 145/1328438.1328472 Available at doi: 10.1 145/1328438.1328472, 

[1 1] Yitzhak Mandelbaum, David Walker & Robert Harper (2003): An Effective Theory of Type Refinements. In: 
ICFP'03, ACM, pp. 213-226 do H 10. 1 145/944705 .9447251 

[12] Dimitris Mostrous & Nobuko Yoshida (2007): Two session typing systems for higher-order mobile processes. 

In: TLCA'07, LNCS 4583, Springer, pp. 321-335 doi: 10.1007/978-3-540-73228-0_23 
[13] Dimitris Mostrous & Nobuko Yoshida (2009): Session-Based Communication Optimisation 

for Higher-Order Mobile Proces ses. In: TLCA'09, LNCS 5608, Springer, pp. 203-218 

doi: 10. 1007/978-3-642-02273-9_T6 

[14] Leonardo de Moura & Nikolaj Bjorner (2008): Z3: An Efficient SMT Solver. In: TACAS, LNCS 4963, 
Springer, pp. 337-340 doi: 10.1007/978-3-540-7880 0-3_24| 

[15] Microsoft Research: F7: Refinement Types for F#. http://research.microsoft.com/en-us/projects/F7/ 

[16] Patrick M. Rondon, Ming Kawaguci & Ranjit Jhala (2008): Liquid types. In: PLDFOS, ACM, pp. 159-169 
doi: 10. 1 145/1 37558 1 . 1 375602 

[17] Bernardo Toninho, Luis Caires & Frank Pfenning (2011): Dependent session types via intuitionistic linear 
type theory. In: Proceedings of the 13th international ACM SIGPLAN symposium on Principles andpractices 
of declarative programming, PPDP' 11, ACM, pp. 161-172 doi: 10. 1 145/2003476.2003499 

[18] Vasco T. Vasconcelos (2012): Fundamentals of Session Types. Information and 

Computation 217, pp. 52-70, doi: 10.1007/978-3-642-01918-0_4| Available at 

http : //www. di . f c.ul .pt/~vv/papers/vasconcelos_fundamental- sessions .pdf Earlier version 
in SFM'09, volume 5569 of LNCS, pages 158-186. Springer, 2009 doi: 10.1007/978-3-642-01918-0_4 

[19] Philip Wadler & Robert Bruce Findler (2009): Well-typed programs can't be blamed. In: ESOP'09, Springer, 
pp. l-16doi il0.1007/978-3 642-00590-9_l| 

[20] Nobuko Yoshida (2004): Channel dependent types for higher-order mobile processes. In: POPL' 04, ACM, 
pp. 147-160 doi: 1 0.1 145/964001.964014 



